Skip to content

Refactor slash-commands workflow for improved clarity and security#388

Merged
riaankleinhans merged 1 commit intomainfrom
update-permissions
May 2, 2026
Merged

Refactor slash-commands workflow for improved clarity and security#388
riaankleinhans merged 1 commit intomainfrom
update-permissions

Conversation

@riaankleinhans
Copy link
Copy Markdown
Contributor

  • Updated comments for better understanding of the workflow structure.
  • Adjusted permissions to explicitly define access levels for contents, issues, and pull requests.
  • Simplified the condition for dispatching slash commands.
  • Updated the labeler action reference to use the latest version from cncf/automation.
  • Enhanced the handling of repository and issue details for better accuracy.

This change aligns with recent updates to improve workflow security and maintainability.

Signed-off-by: Riaan Kleinhans <riaankleinhans@gmail.com>
@github-actions github-actions Bot added needs-triage Indicates an issue or PR that has not been triaged yet (has a 'triage/foo' label applied) needs-kind Indicates an issue or PR that is missing an issue type or kind (a kind/foo label) needs-group Indicates an issue or PR that has not been assigned a group (toc or tag/foo label applied) needs-priority Indicates an issue or PR missing a priority label needs-area Indicates an issue or PR missing an area label needs-status Indicates an issue or PR missing a status label labels May 2, 2026
@riaankleinhans riaankleinhans merged commit d3d9690 into main May 2, 2026
2 of 3 checks passed
@kusari-inspector
Copy link
Copy Markdown
Contributor

Kusari Inspector

Kusari Analysis Results:

Do not proceed without addressing issues

Caution

Flagged Issues Detected
These changes contain flagged issues that may introduce security risks.

The dependency analysis found no issues. However, the code analysis identified a least-privilege violation in .github/workflows/slash-commands.yml: 'issues: write' and 'pull-requests: write' permissions are declared at the workflow level rather than scoped to the specific job that requires them. This unnecessarily exposes all jobs in the workflow to broad write permissions. If any job in this workflow were compromised (e.g., via a malicious dependency or injected input), an attacker could leverage these inherited write permissions to tamper with issues or pull requests. The fix is straightforward: move the write permissions down to the specific job (dispatch-slash-command) that needs them, and set the top-level permissions block to read-only (contents: read). This must be addressed before merging.

Note

View full detailed analysis result for more information on the output and the checks that were run.

Required Code Mitigations

Move write permissions from the workflow level to the specific job level. Keep the top-level permissions block minimal (read-only) and add the required write permissions directly under the job that needs them.

permissions:
  contents: read

jobs:
  dispatch-slash-command:
    name: Dispatch Slash Command
    permissions:
      issues: write
      pull-requests: write

@kusari-inspector rerun - Trigger a re-analysis of this PR
@kusari-inspector feedback [your message] - Send feedback to our AI and team
See Kusari's documentation for setup and configuration.
Commit: 7548223, performed at: 2026-05-02T20:29:12Z

Found this helpful? Give it a 👍 or 👎 reaction!

- remove-help-command

permissions: {}
permissions:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue: Move write permissions from the workflow level to the specific job level. Keep the top-level permissions block minimal (read-only) and add the required write permissions directly under the job that needs them.

Recommended Code Changes:

permissions:
  contents: read

jobs:
  dispatch-slash-command:
    name: Dispatch Slash Command
    permissions:
      issues: write
      pull-requests: write

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-area Indicates an issue or PR missing an area label needs-group Indicates an issue or PR that has not been assigned a group (toc or tag/foo label applied) needs-kind Indicates an issue or PR that is missing an issue type or kind (a kind/foo label) needs-priority Indicates an issue or PR missing a priority label needs-status Indicates an issue or PR missing a status label needs-triage Indicates an issue or PR that has not been triaged yet (has a 'triage/foo' label applied)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant